These best practices are guidelines that CygNet suggests that you adopt for building your scripts. They are based on lessons learned over several years of installing and maintaining CygNet systems. They reflect feedback we have received from customers, systems integrators, and our own engineers. Adherence to these best practices may likely save you considerable time, money, and frustration as you begin to take advantage of CygNet’s scripting environment.
Prior to creating a large number of scripts for either CygNet Studio or for the HyperPoint Scripting Service, take the time to establish some style guidelines for creating your script. As with any flexible programming environment, the CygNet scripting environment provides you with many options for convention and style that you may adopt. Although the syntax of Microsoft Visual Basic script and the functions provided by the libraries are fixed, how you indent your code, add comments, name variables, handle error conditions and much more is up to you. Early adoption of a set of coding conventions will dramatically improve the maintainability of your script and form a solid foundation for expanding the system in the future. Since many of the examples provided in the reference guide have been extracted from production systems, you will find that the examples show a variety of styles and conventions. One style may or may not be superior to another, but deciding on one style and sticking with it is certainly a superior strategy.
Note: When working with very large integers in script (15+ characters), be careful when incrementing by small values, as the value displayed may not reflect the actual value. This restriction is imposed by the way VB Script handles floating point calculations.
You are given the option of where you write the results of the script processing. You may write results into the HSS point for which the script is associated, or you can write to any other point in a HSS or UIS. In most cases, it is better to use the value of the HyperPoint for the status of the script itself such as "INIT" to indicate that the HyperPoint has been initialized, "SUCCESS" to indicate successful script processing, and "FAILED" to indicate that a problem occurred in the script processing. This way, it is easy to make a visual health check of the scripts in the HSS, and you can alarm and get history of the problems that occur. Additionally, if you would like to use a numeric trending tool such as the Trend Tool, you can add a number at the beginning of the status description for the value such as "2:FAILED." The history of the status for scripts may then easily be trended.
It is usually better to write the results of calculations performed by scripts into points on a UIS. This practice will help insure that data associated with a device or a process are grouped with other associated point data. Browsing point data and developing templated human-machine interface (HMI) screens will then be much easier for our users and screen developers.
Scripts may be set to run on a timed basis using the provided Timer.Set function. This works well in many situations, but is not a good solution for handling a large number of related scripts or applying more complex timed execution sequences. When you want to have many scripts run at the same time or when you need more flexibility in scheduling, use the Master Scheduling Service to run the scripts. The advantages include:
When using the MSS for scheduling the execution of scripts, create a "trigger" point in the HSS that you can reference in each of the related scripts. You will then set the MSS to perform a setpoint request to the trigger point. This will in turn trigger the script to process.
A very valuable technique for creating a large number of scripts is to first create a template script and then copy the template script repeatedly until all scripts are entered. To limit the number of point specific changes necessary for each copied script, reference point tags in the script using the points' FACILITY/UDC designation. In this way, you can be clever in your script and dynamically reference either the facility or the UDC to reference a point and avoid having to enter specific point tag Ids in each script.
|
|
|
